Mailing lists
There is one way to get in contact with the SvxLink "community". That is through the mailing list. The address to the mailing list is svxlink-devel@lists.sourceforge.net. So, whatever your business is, please use the mailing list. Do not use EchoLink or direct e-mail to the author. The list is very low volume so don't be afraid to register.There are a couple of reasons why only the mailing list should be used for support:
- There are more people that can help. I only use RedHat Linux but there are people on the mailing list that have gotten SvxLink to work under other distributions.
- Documentation. All mails sent to the mailing list get stored in the mailing list archive. A good way to find solutions to problems is to search the archive.
- Other people subscribing to the mailing list might get helped by the discussion.
There is also another mailing list svxlink-announce@lists.sourceforge.net, which is even lower volume. Just a single mail per SvxLink release, which is not that often. If you join the svxlink-devel list there is no need to join the svxlink-announce list.
To subscribe to the mailing lists go here.
Reporting bugs
Bugs should be reported to the svxlink-devel
mailing list mentioned above. It can be hard filing a good bug report. But
I assure you, it is even harder to understand a bad bug report. So, if you
find a bug, take the time to go through the steps below to make a good bug
report.
- Read the documentation thoroughly to verify that you have not misunderstood something. This includes the installation documentation, the svxlink server docs and the qtel docs, depending on what application you found the bug in.
- If possible, try to reproduce the bug. A way to reproduce the bug makes it much easier for the developer to find and fix the bug. If is is not possible to reproduce it, try to remember what happened right before the bug appeared. Include a detailed step by step instruction in the report of how to reproduce the bug.
- Write a bug report and send it off to the svxlink-devel mailing
list. The bug report should include the following:
- A detailed description of the bug. Do not just write "this feature does not work". Explain in what way it does not work. There can be many ways for a certain feature to fail.
- If possible, describe how to reproduce the bug.